I fixed up the file of this morning's message (but still have a listing
in case you want to see it) but it still "DRYROTS".  The file is
TRY.SAI[G,MJC].  Is there something special I should know about for-stmts?
					Mike Clancy

17-NOV-72  1742		G,MJC
A program which I wrote to try to learn a few things (namely SAIL and the
Quam display routines) uncovered a "DRYROT" error.  The program is 
TRY.SAI[G,MJC], and the error occurred in line 2600.  Any suggestions?
					Mike Clancy

JAM again. Sorry, it doesn't go away with
an "IF TRUE THEN", only with an "IF FOO THEN"

22-NOV-72  2344		MA,JAM
JAM here bringing to you yet another
insidious SAIL bug. There is a program
BUG.SAI[MA,JAM] which compiles the following
code incorrectly (see page 6 of source file):

	BEGIN "FLTO"
	    REAL ARRAY Y[1:LN+GWIDTH];
	    *** LOTS OF STUFF ***
	END "FLTO";
	BEGIN "DPGT"
	    INTEGER ARRAY BUF[1:5500];
	    *** MORE STUFF ***
	END "DPGT";

The following code appears:

DPGT&DPGT.-6/	PUSHJ P,BEXIT
DPGT&DPGT.-5/	PUSH P,3	; LOWER ARRAY BOUND???
DPGT&DPGT.-4/	PUSH P,[=5500]	; THIS IS OK
DPGT&DPGT.-3/	PUSH P,3	; IT SEEMS TO THINK AC3 CONTAINS A 1
DPGT&DPGT.-2/	PUSHJ P,ARRMAK

This, of course, gets a "UPPER BOUND<LOWER BOUND" error
message, for constant bounds yet! Anyway, the problem
goes away if you put an "IF TRUE THEN" in front of
the BEGIN "DPGT". Is that enough?

22-NOV-72  2341		MA,JAM
Dear Ail,
  CASE n OF (ITV, ITV, ... ITV) generates, in at least one case

	<case check>
	JRST	@TABLE(IDX)
	PUSH	P,ITV
	JRST	DONE
	...
	PUSH	P,ITV
	JRST	DONE
TABLE:	.-...
	.-...
	...
	TABLE-2
DONE:	POP	P,TBITS2
	MOVE	A,0			;!!!!!!!!!!!
	....
 This is fairly recent (MOVE s/b MOVE A,TBITS2 or whatever).

DCS

20-NOV-72  0341		SLS,DCS
I RAN INTO PROBLEMS WHEN USING THE SAIL DPB COMMAND.
THE CODE GENERATED FOR THE INSTRUCTION
	DPB(A,POINT(11,BUFX[POINTER],10))
	SEEMED TO LOAD A INTO REGESTER 10 AND PROMPTLY DEPOSIT REG 11.
THE PROGRAM IS TEST.SAI ON [1,EMC], AND THE OFFENDING LINE IS IN THE
AIVCT1 PROCEDURE FOUND ON PAGE 4, I BELIEVE.
19-NOV-72  0831		1,EMC
HELP!
DON'T PUT UP THE NEW SAIL.
TWO DEMOS ON MONDAY.  THIS WOULD
BE THE 4TH DEMO IN SUCCESSION IMMED
AFTER A SAIL CHANGE.
TOB
07-DEC-72  1419		H,HJS
K PINGLE FOUND A BUG HAVING TO DO WITH AN ILLEGIT. ARRAY NAME IN AN
ARERR UUO FOR COMPLICATED EXPRS.  SERIOUS ENOUGH TO FIX.  SEE BUG #KR.
DCS

06-DEC-72  2219		SLS,DCS
NASTY BUG IN SAIL SETBREAK(TABLE,STRDELIM,STRDELETE,SWITCHES);
IF YOU DO A SETBREAK WITH CHARACTERS TO BE DELETED,
THEN LATER IN THE PROGRAM YOU DO ANOTHER SETBREAK ON THE SAME TABLE NUMBER
WITH NULL STRDELETE, IT CONTINUES TO USE THE OLD STRDELETE!!!!

06-JAN-73  1737		1,REM
Is my observation correct? I have a block full of
CONTINUEs, and I find that the first one jumps to
the second, the second jumps to the third, and so
on to the last one!!???

04-JAN-73  0959		MA,JAM
The SAIL error: BEGIN AND END DO NOT MATCH
could be more helpful in telling which are
the BEGIN block names.

19-DEC-72  1609		WRU,TOB
JAM here. I have a SAIL program that I said ↑C - SAVE
to. The dump copy is SAVBUG.DMP[MA,JAM]. If you RUN it,
it generally says "ERROR IN JOB 26, PC EXCEEDS MEM BOUND
AT USER 400013", indicating to me that the second segment
isn't hooked up. If you GET it and START it, sometimes it
works and sometimes not. This doesn't seem to happen if I
SAVE the program before it is ever run for the first time.
If I start it up, then stop it and save it, this often
happens.
	Please delete the file SAVBUG.DMP[MA,JAM] when
you are finished with it.

18-DEC-72  1151		MA,JAM
export version of sail should not have dump never bit on in
rel files created. fancyy technique for writing over ddt doesn't seem
to work with export.
                  jim low

16-DEC-72  1444		S,JRL
THE 7-LINE PROGRAM BUG.SAI[1,REM] COMPILES INCORRECTLY BY SAIL.
JNAM←CVSIX("[LXGP]"); COMPILES AS MOVSI NIC,0;MOVEM NIC,JNAM;

14-JAN-73  1824		1,REM
YOU OUGHT TO FIX SAIL SO YOU CAN SPECIFY ODD FILE NAMES, LIKE [-AP-].DMP
IN AN ENTER.  PERHAPS, ADOPT THE COPY CONVENTION ABOUT ↓ TO SURROUND A
QUOTED NAME.

01-FEB-73  1236		TAP,REG
There is a deeper bug but you can cure your immediate problem by parenthesizing
the expression TK([A⊗O≡V]) in your macro IV. Syntactically the parens are
required since a boolean expression inside a foreach associative context musht
be parenthesized.
	jim

06-FEB-73  1126		S,JRL
	IT USED TO BE THAT INCHWL WAS ONLY TERMINATED BY <CRLF> NOT
BY <ALT> OR <LF> OR BARE <CR> OR ANY OTHER ACTIVATION CHARACTER.
A FEW MONTHS AGO INCHWL BEGAN TO BE TERMINATED BY THE OTHER ACTIVATION
CHARACTERS AS WELL.  THIS LASTED FOR ABOUT A MONTH, THEN RETURNED TO
THE <CRLF> ONLY METHOD.  NOW TONITE I FIND THAT INCHWL IS AGAIN TERMINATED
BY ANY ACTIVATION CHARACTERS.  WHY DOES IT KEEP CHANGING???

06-FEB-73  0124		1,REM
The next person to make a new compiler might have some KVL typos to contend
with (Gen pg 51,52,53 and Hel pg 15) due to implementation of ACCESS.  The
slow system prevents me from making a compiler myself today.
			-peace and love - KVL

06-MAR-73  1430		1,KVL
BOTH OLD AND NEW PUB USE SAISG5 VERSION; BUT THE NEW CORE IMAGE IS
3K BIGGER THAN IT USED TO BE 7 WEEKS AGO.  ANY IDEA WHY?  I ONLY
ADDED A LINE OR TWO OF CODE. (COMPARE PUB2.DMP AND PUB2.OLD
ON [1,3]).
--- LARRY TESLER

05-MAR-73  1151		2,TES
Russ: We need to fix the realin (intin) and any associated code

to handle overflow conditions by having a JFCL immediately following
any instruction which can cause an overflow.  In particular, realin
with a large integer part followed by a large number of fraction part
zerowill cause an overflow.



14-MAR-73  2024		1,PDQ
RUSS: I GOT A "DRYROT AT EFORM" MESSAGE WHEN TRYING TO COMPILE
FILE AESTH.SAI[A,JEG]. DAN SAID IT WAS A COMPILER ERROR AND THAT
YOU ARE THE PERSON TO SEE. SUGGESTIONS? THANKS. 
				   - JIM

07-APR-73  1850		A,JEG
 
∂15-MAY-73  0329		2,TES
 The new version of SAIL will not compile PUB.
 See PPSAV.PUB[2,TES].  I tried twice.
 Larry
 
 
∂15-MAY-73  0202		SLS,DCS
 Larry Tesler couldn't get PUB up with new segment, so I
 managed to get one running with SAISG5.513, SSAVED it
 and changed named of segment to SAISGN -- put it on the
 system.  The old dmp is PUB.DMP[
 (sorry) PUB.DMP[SLS,DCS] if you want to try again, else
 please delete it.  Larry will probably follow advice and
 put it up with the library, at least for a while, soon.
 Dan
 
 
∂15-MAY-73  0648		GEM,TVR
 Thank you for the pleasure of reloading my program because of change to SAISG5!
 
∂04-JUN-73  1245		SLS,DCS AT TTY62 
 Sorry -- wasn't careful enuf in my examination of the problem.  SGLIGN
 is MISSING from HLBSA5, tho PRESENT in LIBSA5!!!!  What a strange
 situation.  I refrained from inserting it, so you could study the
 anomaly in situ if you wished.
   Dan
 
∂04-JUN-73  1025		LDE,DCS
 IS THERE ANY GOOD REASON THAT POW & FPOW ARE NOT MADE "HERE"??  SINCE THE
 COMPILER CALLS THEM DIRECTLY, SOMETIMES, ANYTIME A NEW SEGMENT IS MADE, A
 NEW COMPILER MUST ALSO NEEDS BE MADE.
 		LEE ERMAN
 
∂03-JUN-73  1105		SLS,DCS
 There are no HEAD syms on either library.  Weiss du das?
 
∂13-JUN-73  0204		1,MSW
  HELLO I AM ONE OF JEENA'S COLLEAGUES. IHAVE A SMALLPROGRAM
 ON MIR.SAI WHICH YOU MAY LIKE TO SEE. IT DOES A LOT OF WIERD
 THINGS. TWO COMMENTS IN THE PROGRAM WILL POINT THE PROBLEMS.
 THEY ARE SYSTEM BUGS OR THE DOCUMENTATION WE HAVE IS 
 OUTDATED. I WOULD LIKE TO HEAR YOUR OPINION ON THIS.
 MY NAME SHRIRAM.
 MY FILE MIR.SAI ON [1,MSW]
 THANX.BYE.
∂19-JUL-73  1102		IML,BO AT TTY113 
 SAIL BUG: USING PORTRAN PROCEDURE ATAN2, THE EXPRESSION
 ATAN2(A-B,C-D) USES THE SAME TEMPORARY STORAGE LOCATION FOR
 BOTH OF THE EXPRESSIONS IN THE CALL.
 
∂04-AUG-73  1526		1,LDE
 Please see LEAP.SAI[1,LDE] ( a five line program) for what seems to be
 a ridiculously basic Leap bug.
 _
∂3-AUG-73  0826		network site CMUA
 An ENDC followed by an ELSEC gives a non-helpful error message of
 ILL MEM REF.  (See BADCOM.SAI[1,LDE) for and example.)
 		Lee Erman
 
∂20-AUG-73  1557		MA,JAM
 Hi. JAM here. I think I have discovered a feature,
 but it might well be considered a bug. Try to
 compile SAIBUG.SAI[MA,JAM] and it will get an
 error on page 8 that says "Not enough params supplied
 to procedure". To save you some looking, the statement
 is:
 	P1←PITCH(NLEND(RG1));
 P1 is a real, RG1 is an integer. PITCH is a macro defined
 on page 4 as:
 DEFINE PITCH(PK)="RGET(PK,1)";
 RGET is defined in LPACK.HDR[MA,JAM] as an integer procedure
 of two integer arguements.
 NLEND is a macro defined on page 5 as:
 DEFINE NLEND(R)="PGET(R,2,TRUE)";
 PGET is defined in LPACK.HDR[MA,JAM] as an integer procedure
 of two integer arguements and one boolean arguement.
 	What seems to happen is that the terminal ",1" in
 the expansion of PITCH seems to get lost. If I put in
 REQUIRE "⊂⊃⊂⊃" DELIMITERS; above the call, it gets past that
 point. As I say, this may be a feature, not a bug, but here
 it is anyway.
∂15-OCT-73  1032		network site MAXC
 -------
 Date: 15-OCT-73 1032
 From: SPROULL at PARC-MAXC
 Re:   Bug in INTMOD
 - - - -
 I belive that there is a bug in the export version of
 INTMOD (interrupt handler) in NWORLD.  I was reading the code,
 preparatory to doing some shit for NIH, and I found this
 exciting mask that is commented "insure only legit bits"
 Unless I am very much mistaken, the person that put together
 that mask counted bits from the left beginning at 1, not 0,;;;
 the result is that the mask is WRONG.  Consult page 3-2 of the
 DEC Assembly Language Book, and behold!!!!
 
 Am I right??
 -------
 
∂08-OCT-73  1322		MA,JAM
 JAM again. With reference to my last note, it
 would appear that the problem is not necessarily
 SAIL's but instead the LOADER's problem. That is,
 if I say EX PP/DUMP, it executes fine but the
 dump file is garbaged. If I say LOA PP then
 SAVE, the dump file is OK. OK? Maybe you ought
 to pass this on to whomever 'fixed' the LOADER,
 whoever that is.
 
∂08-OCT-73  1314		MA,JAM
 Hi. JAM here with another SAIL bug. If I SAVE my
 program with the indicated amount of core from the
 LOADER, it gets "RELEASE&: INVALID CHANNEL NUMBER"
 If I SAVE it in one more K than that, it works fine.
 See for yourself. The failing version is BUG.DMP[MA,JAM],
 the winning version is PP.DMP[MA,JAM]. Source file
 is PP and is assembled alone. To run:
 
 RU BUG[MA,JAM]
 Input file:	JJJ.SND[SND,JAM]
 Output file:	FOO.TMP
 Clock rate:	20000
 Lower frequency bound:	50
 Upper frequency bound:	300
 Step in Ms:	5
 stp = 100
 Decay constant =   .9480775
 Min. frequency resolution in Hz:	1
 167 frequency points
 
 at this point, program will either immediately
 fail or start computing ad infinitum. Happy
 hunting. P.S., this is not unique to this program,
 I have several others that exhibit this behavior.
∂19-OCT-73  1450		2,MLM AT TTY110 
 SAIL PEOPLE: Found a DRYROT.  I know what the mistake in the source file
 is, but you might be interested in the compiler problem that causes this
 DRYROT message.  Compile DRYROT.SAI[2,MLM] and you will get message.
 You may copy, delete, etc. this file.
∂21-OCT-73  2140		204,MLM AT TTY110 
 SAIL PEOPLE: Have found another DRYROT; I know what's wrong but again
 thought you might be interested.  Should I bother reporting these as
 the Monitor manual suggests, or are they so common as not to bother?
 All files on [2,MLM] produce DRYROT messages because of stupid mistakes
 (in fact these are stupid programs altogether, the product of my rather
 empirical method for learning SAIL; my apologies to your sensibilities)
 and are yours to play with and delete.